PBSA Admin Portal
3+ years. 9+ modules. Solo designer.
I was hired as a designer. I became the designer, PM, and QA. Four frontend developers, no dedicated PM, no design reviews. 3+ years. 9+ modules. This is what I learned.
Revisited in 2026
Originally designed and shipped in 2024, I revisited the PBSA Admin Portal following an updated brand identity and the rapid evolution of AI-assisted product development. I redesigned the experience around the new visual system, revisited several product and UX decisions, and used AI throughout the design-to-build workflow to turn the case study into a functional browser-based prototype.
The starting point
I joined Viva City as a designer. The company had purchased a design template. My assignment: adapt it across the entire platform.
What actually happened was different. I became the solo designer and the de facto product manager and the only person doing design QA. Four frontend developers reported to someone else. I reported to no one.
The stakes were real — regional managers across the UK depended on this platform to run their student accommodation businesses. The timeline was aggressive. The support was minimal.
Admin platform — 9+ modules
- Dashboard Real-time enquiry metrics and property performance.
- Enquiries Unified inbox across multiple channels.
- Properties Content management, CRM integration, CSV bulk import.
- And more Articles, Promotions, Tracking, AI Assist, Contacts, Surveys.
Student-facing product
- WeChat Mini Program Discovery and enquiry submission.
- Scope
- 3+ years of work
- Team
- Me (design)
- Validation
- Always post-launch, never before
Design systems aren't optional, they're foundational
We built module-by-module without a shared component library. Dashboard buttons looked different from Enquiries buttons. Same platform, different visual languages.
I found the inconsistency during QA. Too late. Fixing it meant rework across multiple modules.
- The lesson
- Foundation first, features second. Build the system before you build the features.
- What I'd do differently
- Establish design tokens, components, and documentation before a single feature ships. Make consistency automatic, not something I have to enforce.
Post-launch validation isn't validation
We shipped the Enquiries module. Post-launch, I discovered the internal notes feature was buggy and became critical for team coordination.
We shipped the Dashboard. Post-launch, I discovered only one of the four metrics actually mattered for daily operations.
Problems caught early are cheap. Problems caught after launch are expensive and damage trust.
- The lesson
- Even lightweight validation — talking to 2–3 users before design locks in — catches assumptions early.
- What I'd do differently
- Talk to operators before finalizing. I didn't need expensive research. I just needed conversations.
Stakeholder alignment during design beats feedback after launch
Stakeholders only saw work after it shipped. That's when they raised concerns. That's when requirements changed. That's when I felt like I'd failed at something I wasn't even involved in planning.
- The lesson
- Problems surface early when you collaborate during design, not after.
- What I'd do differently
- Weekly stakeholder checkpoints at 25%, 50%, 75% complete. Show work in progress. Catch misalignment when it's cheap to fix.
Technical constraints shape what design is actually possible
I designed search and filter flows assuming instant client-side filtering. Post-development, the pagination and API architecture made that impossible. Multiple loading states felt janky and confused users.
- The lesson
- Design without understanding technical reality leads to friction and rework.
- What I'd do differently
- Before finalizing designs, have a real conversation with the tech lead. Understand what's easy, expensive, and impossible. Design within technical reality, not against it.
What actually worked
Enquiry Management. When I got the problem statement right — operators need unified communication and context in one place — everything else followed. Internal notes became the default handoff mechanism. Duplicate replies dropped. Team coordination improved.
Properties module. CSV bulk import with manual review checkpoints caught data quality issues before they hit production. Automation served the user, not the other way around.
These two modules proved what's possible when you frame the problem correctly.
The real realization
I used to think: "I can design anything. I can figure anything out. Give me a problem and a timeline and I'll ship it."
I design best with clarity upfront, collaboration during design, and team support during execution.
This isn't about capability. I've proven I can execute under constraints. It's about environment. A constraint is a signal about what's missing.
What I need to do my best work
- Design is valued as strategy, not visual decoration.
- I collaborate during discovery, not just execution.
- Stakeholders align during design, not feedback after.
- I work alongside people who specialize in their crafts.
- I can focus on product thinking and design systems.
PBSA taught me what I'm genuinely good at. It also taught me what environment I need to do my best work.
Each explores one of these lessons in depth.